Azure テナント
Azure AD の信頼された専用インスタンスであり、組織が
Microsoft Azure、Microsoft Intune、Microsoft 365 などの Microsoft
クラウド
サービスのサブスクリプションにサインアップしたときに自動的に作成されます。
1 つの Azure テナントは単一の組織を表します。
Microsoft が、現在提供しているクラウドベースサービス
・Microsoft
Azure
・Microsoft 365
・Microsoft Intune
・Microsoft Dynamics
365
それらのすべてのサービスで、Azure AD
を使用して、ユーザーを識別し、アクセスを制御することができる
Azure サブスクリプションと Azure AD の管理者
Azure サブスクリプションと Azure AD
には包含関係は無く、独立しています。
Azure サブスクリプションは、必ず
1 つの Azure AD に関連付けられています (*注1)
ので、両者の関係性は次のような図になります。
管理者についてもそれぞれ独立していますので、
Azure
サブスクリプションの管理者であっても Azure AD の全体管理者でなければ、
Azure AD の管理 (ユーザー追加、削除など) はできません。
同様に Azure
AD の全体管理者であっても、必ずしも紐づく Azure
サブスクリプションの管理者ではありません。
認証を受けることができるもの。
ID
は、ユーザー名とパスワードを持つユーザーの可能性があります。
ID
には、秘密キーまたは証明書による認証を必要とする可能性があるアプリケーションまたはその他のサーバーも含まれます
Azure AD またはそれ以外の Microsoft クラウド サービス (Microsoft 365
など) を通じて作成される ID です。
ID は Azure AD
に保存され、組織のクラウド サービスのサブスクリプションで利用できます。
このアカウントは、職場または学校アカウントと呼ばれることもあります。
Azure AD テナントは、組織で使用されるアプリケーションとリソースに ID
とアクセス管理 (IAM) 機能を提供します。
ID
は、リソースへのアクセスを認証および承認できるディレクトリ
オブジェクトです。
ID オブジェクトは、学生や教師などの人間の
ID、教室や学生のデバイス、アプリケーション、サービスの原則などの人間以外の
ID に対して存在します。
Azure ADテナントは、組織の IT
部門の管理下にある ID セキュリティ境界です。
このセキュリティ境界内では、オブジェクト (ユーザー オブジェクトなど)
の管理とテナント全体の設定の構成は、IT 管理者によって制御されます。
Microsoft が、現在提供しているクラウドベースサービス
・Microsoft
Azure
・Microsoft 365
・Microsoft Intune
・Microsoft Dynamics
365
それらのすべてのサービスで、Azure AD
を使用して、ユーザーを識別し、アクセスを制御することができる
企業または組織が、これらのサービスの
1 つを使用するためにサインアップすると、
既定の
“ディレクトリ”、つまり Azure AD のインスタンスが割り当てられる
この
“ディレクトリ”には、企業が購入した各サービスにアクセスできるユーザーとグループが保持される
この既定のディレクトリは、“テナント”
と呼ばれる
Azure Active Directory テナントの作成
Microsoft 365
Educationの有料サブスクリプションまたは試用版サブスクリプションにサインアップすると、基になるOffice
365 サービスの一部として Azure Active Directory (Azure AD)
テナントが作成されます。
同様に、Azure にサインアップすると、Azure
AD テナントが作成されます。
また、Azure portalを使用して Azure AD
テナントを手動で作成し、後でOffice 365
サービスを追加することもできます。
Azure ADテナント作成/Azureサブスクリプション契約時に検討すべきこと TAG Azure
Azureの利用する場合、Active
Directoryを保有しているかどうかに関わらずAzure
ADテナントの作成が必須になります。
これは、Azureで使用するユーザはAzure
ADで管理する必要があるためです。
また、実際のAzureリソースはAzureサブスクリプションと呼ばれるAzureアカウント上に作成されますが、このAzureサブスクリプションは必ずAzure
ADテナントに紐づいています。
Azureテナントはディレクトリであり、ユーザーやグループなどのアイデンティティ情報を管理する単位です。
Azureサブスクリプションは、リソースを配置できる「フォルダー」を表すオブジェクトであり、課金や制限などの設定が可能です。
サブスクリプションはテナントに関連付けられています。
したがって、1つのテナントは多くのサブスクリプションを持つことができますが、その逆はできません。
テナントは単一の
ID(個人、会社、または組織)に関連付けられており、1つまたは複数のサブスクリプションを所有できます。
Azure サブスクリプションと Azure AD について
Azure サブスクリプションを Azure Active Directory テナントに関連付けるまたは追加する
すべての Azure サブスクリプションには、Azure Active Directory (Azure
AD) インスタンスとの信頼関係があります。
サブスクリプションは信頼された Azure AD に依存して、セキュリティ
プリンシパルとデバイスの認証と承認を行います。
サブスクリプションの有効期限が切れると、Azure AD
サービスの信頼されたインスタンスは残りますが、セキュリティ
プリンシパルでは、Azure リソースへのアクセスができなくなります。
サブスクリプションは 1 つのディレクトリのみを信頼できますが、1 つの
Azure AD は複数のサブスクリプションから信頼されることができます
ユーザーが Microsoft のクラウド サービスに新規登録すると、新しい
Azure AD テナントが作成され、そのユーザーは全体管理者ロールに属します。
ただし、サブスクリプションの所有者が自分のサブスクリプションを既存のテナントに参加させるとき、その所有者は全体管理者ロールに割り当てられません。
AzureサブスクリプションとかアカウントとかAzure ADのテナントとか (1)
Azure Active Directory のロールについて
ディレクトリ内の Azure AD
リソースの管理に使用されます。
たとえば、
ユーザーの作成や編集、
他のユーザーへの管理ロールの割り当て、
ユーザー
パスワードのリセット、
ユーザー
ライセンスの管理、
ドメインの管理など
このロールのユーザーは、Microsoft 365 の各サービスにわたって設定と管理情報を読み取ることができますが、管理アクションを実行することはできません。 グローバル閲覧者は、全体管理者に対応する読み取り専用のロールです。
グローバル管理者を含む Azure AD の特権ロール付与や Privileged Identity Management (PIM) 機能を管理することができる
このロールのメンバーは、グループの作成と管理、名前付けと有効期限ポリシーなどのグループ設定の作成と管理、グループのアクティビティと監査レポートの表示を行うことができます。
次のセキュリティ関連機能を管理するアクセス許可あり
Microsoft 365
Defender ポータル、Azure Active Directory Identity Protection、Azure
Active Directory Authentication、Azure Information Protection、Microsoft
Purview コンプライアンス ポータル
管理者以外とパスワード管理者のパスワードをリセットできます。
このロールのユーザーは、エンタープライズ アプリケーション、アプリケーション登録、アプリケーション プロキシの設定の全側面を作成して管理できます。
このロールのユーザーは、
[ユーザーはアプリケーションを登録できる]
設定が [いいえ]
に設定されている場合に、アプリケーション登録を作成できる。
[ユーザーはアプリが自身の代わりに会社のデータにアクセスすることを許可できる]
設定が [いいえ]
に設定されている場合に、代わりに同意する権限を付与します。
新しいアプリケーション登録を作成する際に、所有者として追加されます。
このロールのユーザーは、(アプリケーション プロキシを管理する権限を除き) アプリケーション管理者ロールと同じアクセス許可を持ちます
購入、サブスクリプションの管理、サポート チケットの管理、サービスの正常性の監視
Azure AD のリソースに対するアクセス許可を管理するためのカスタムロール
Azure Active Directory のロールベースのアクセス制御の概要
Azure portal を使用して Azure カスタム ロールを作成または更新する
カスタム ロールの作成を開始するには、次の 3
つの方法
・ロールを複製
・最初から行う
・JSON から始める
1.Azure portal で、カスタム
ロールを割り当て可能にするサブスクリプションまたはリソース
グループを開き、 [アクセス制御 (IAM)] を開きます。
⒉.[ロール]
タブをクリックして、すべての組み込みおよびカスタム
ロールの一覧を表示
複製するロールを検索
Azure Active Directory でカスタム ロールを作成して割り当てる
Azure Active Directory>[ロールと管理者]>[新しいカスタム ロール]
Azure Active Directory のタスク別の最小特権ロール
2 種類のグループと 3 種類のグループ メンバーシップがあります
Azure Active Directory のグループとアクセス権の詳細
Azure AD管理センターの内容解説【MicrosoftのMVP解説!第三弾 Microsoft 365の活用術】
Azure AD グループを使用してロールの割り当てを管理する
グループにロールを割り当てるには、isAssignableToRole プロパティが true に設定された新しいセキュリティ グループまたは Microsoft 365 グループを作成する必要があります
Azure AD グループを使用してロールの割り当てを管理する
グループの入れ子化はサポートされていません。 グループは、ロール割り当て可能なグループのメンバーとして追加することはできません。
セキュリティ: 共有リソースに対するユーザーとコンピューターのアクセスを管理するために使います
たとえば、セキュリティ
グループを作成し、グループの全メンバーに同じセキュリティ
アクセス許可セットが付与されるようにすることができます。
セキュリティ
グループのメンバーには、ユーザー、デバイス、他のグループ、サービス
プリンシパルを含めることができます。これにより、アクセス
ポリシーとアクセス許可を定義します。
セキュリティ
グループ所有者には、ユーザーとサービス
プリンシパルを含めることができます。
Microsoft 365: 共有メールボックス、カレンダー、ファイル、SharePoint サイトなどへのアクセス権をグループ メンバーに付与することで、共同作業の機会を提供します
組織外のユーザーにグループへのアクセス権を付与することもできます。
Microsoft 365
グループのメンバーには、ユーザーのみを含めることができます。
Microsoft 365 グループ所有者には、ユーザーとサービス
プリンシパルを含めることができます
Azure Active Directory で削除された Microsoft 365 グループを復元する
Azure Active Directory (Azure AD) で Microsoft 365
グループを削除すると、削除されたグループは表示されなくなりますが、削除日から
30 日間は保持されます。
この動作は、必要に応じて、グループとその内容を復元できるようにするためです。
この機能は、Azure AD の Microsoft 365 グループに限定されます。
グループの名前付けポリシーとは、ユーザーが作成するグループの名前に一貫性を持たせるための機能です。
プレフィックスやサフィックスを使って、グループの役割やメンバー、地域などを表現できます。また、不適切な単語の使用をブロックすることもできます
名前付けポリシーは、Microsoft 365
グループに適用されます。
これには、Outlook、Microsoft
Teams、SharePoint、Planner、Yammer などのグループ
ワークロードが含まれます。
配布グループにも名前付けポリシーを適用できます。
Azure Active Directory での Microsoft 365 グループに対する名前付けポリシーの適用
名前付けポリシーは、全体管理者やユーザー管理者などの特定のディレクトリ
ロールには適用されません
既存の Microsoft 365
グループの場合、ポリシーは構成時にすぐには適用されません。
グループ所有者がこれらのグループのグループ名を編集すると、変更が行われていなくても、名前付けポリシーが適用されます。
Azure Active Directory で動的グループを作成または更新する
Azure Active Directory の動的グループ メンバーシップ ルール
特定のユーザーをグループのメンバーとして追加し、固有のアクセス許可を付与することができます
動的メンバーシップ ルールを使用して、メンバーを自動的に追加および削除できます
動的なグループ ルールを使用して、自動的にデバイスを追加および削除できます
Azure リソースへのアクセスを必要とするすべてのユーザーには、Azure ユーザー アカウントが必要
Azure Active Directory を使用して最近削除されたユーザーを復元または削除する
ユーザーを削除した後、アカウントは 30
日間、中断状態のままになります。
その 30 日の期間中は、ユーザー
アカウントをそのすべてのプロパティと共に復元することができます。
このカテゴリのユーザーは、Azure AD 内にのみ存在し、他のオンプレミス
AD サーバーには存在しません。
これらのユーザーのソースは Azure AD
になります。
このカテゴリのユーザーは、Azure
クラウド環境に取り込む予定のオンプレミス AD
に元々存在していた。
これを行うには、Azure AD Connect
を利用した同期アクティビティを使用して、これらのユーザーを Azure AD
に取り込み、オンプレミスと AD のクラウド
インスタンスの両方に存在できるようにします。
これらのユーザーは Azure の外部に存在します。
例として、他のクラウド プロバイダーのアカウント、Xbox LIVE
アカウントなどの Microsoft アカウントがあります。
そのソースは、招待されたユーザーです。
この種類のアカウントは、外部ベンダーや請負業者が Azure
リソースへのアクセスを必要とする場合に便利です。
ヘルプが不要になったら、アカウントとすべてのアクセス権を削除できます。
Azure AD の UserPrincipalName の設定
UserPrincipalName は、インターネット標準 RFC 822 に基づく属性で、ユーザーのインターネット形式のログイン名となります。
Azure Active Directory でのユーザーの一括作成
必須値は、 [名前] 、 ユーザー プリンシパル名 、 [初期パスワード] 、および [サインインのブロック (はい/いいえ)] のみ
Azure Active Directory の External Identities
外部ユーザーが自分の好みの ID を使用して Microsoft アプリケーションや他のエンタープライズ アプリケーション (SaaS アプリ、カスタム開発アプリなど) にサインインすることで、外部ユーザーと共同作業を行います。 B2B コラボレーション ユーザーはディレクトリで表され、通常はゲスト ユーザーとして表示されます。
Azure Active Directory (Azure AD)
を使用して、組織外のユーザーと協力して作業できる機能
外部コラボレーションの設定を有効にすると、ゲストユーザーを招待したり、特定のドメインを許可したりブロックしたり、ゲストユーザーのアクセス権限を制限したりすることができます
Azure Active Directory (Azure AD) をオンプレミスの AD と同期することで、従業員の ID の管理を一元化できます。
Azure Active Directory でのハイブリッド ID とは
3 つの認証方法のうち 1 つを使用できます。 次に 3
つの方法を示します。
- パスワード ハッシュの同期 (PHS)
-
パススルー認証 (PTA)
- フェデレーション (AD
FS)
これらの認証方法でも、シングル
サインオン機能が提供されます
Azure Active Directory ハイブリッド ID ソリューションの適切な認証方法を選択する
Azure AD のパスワード ハッシュ同期
Azure AD
でオンプレミスのディレクトリ
オブジェクトの認証を有効にする最も簡単な方法
ユーザーはオンプレミスで使用しているものと同じユーザー名とパスワードを使用できる
追加のインフラストラクチャを展開する必要はない
Azure AD パススルー認証
1 つ以上のオンプレミス
サーバーで実行されているソフトウェア エージェントを使用して、Azure AD
認証サービスに簡単なパスワード検証を提供する
オンプレミスの Active
Directory
を使用してサーバーで直接ユーザーが検証され、クラウドでパスワードの検証が行われることはない
オンプレミスのユーザー
アカウントの状態、パスワード
ポリシー、およびサインイン時間をすぐに適用するセキュリティ要件のある企業は、この認証方法を使用する
フェデレーション認証
Azure AD
は別の信頼された認証システム (オンプレミスの Active Directory
フェデレーション サービス (AD FS) など)
に、ユーザーのパスワードを検証する認証プロセスを引き継ぐ
Azure AD
全体管理者アカウントに対する資格情報は、インストール中にのみ使用されます。
このアカウントは、Azure AD に変更を同期する Azure AD コネクタ
アカウントを作成するために使用します。
また、このアカウントにより、同期が Azure AD
の機能として有効化されます。
AD DS エンタープライズ管理者アカウントは、Windows Server AD
の構成に使用されます。
これらの資格情報が使用されるのは、インストール中のみです。
ドメイン管理者ではなく、エンタープライズ管理者が、すべてのドメインで
Windows Server AD
内のアクセス許可が設定できることを確認する必要があります。
DirSync
からアップグレードする場合は、
AD DS
エンタープライズ管理者の資格情報を使用して、DirSync
で使用されていたアカウントのパスワードをリセットします。
Azure AD
グローバル管理者の資格情報も必要になります。
Azure AD Connectを使ってアカウントを同期する方法
Azure AD Connect 同期 の 既定の構成 を表示したり変更したりするツール
Azure AD Connect 同期: 既定の構成に変更を加える
Azure AD Connect 同期: フィルター処理の構成
フィルター処理を使用することによって、オンプレミスのディレクトリからどのオブジェクトを Azure Active Directory (Azure AD) に反映するかを制御できる
オブジェクトの属性値に基づいてオブジェクトをフィルター処理
オブジェクトの種類ごとに異なるフィルターを使用することもできる
Azure Active Directory ハイブリッド ID ソリューションの適切な認証方法を選択する
Azure AD Connect は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスに向けて、ユーザーのパスワードのハッシュと同期します。
パスワード ハッシュ同期は、展開、メンテナンス、インフラストラクチャに関して最小の作業量
Azure Active Directory パススルー認証とは
Azure Active Directory (Azure AD) パススルー認証を使用すると、ユーザーは同じパスワードを使用して、オンプレミスのアプリケーションとクラウド ベースのアプリケーションの両方にサインインできます。
信頼できる外部システムを利用してユーザーを認証する
フェデレーション
システムへの既存の投資を Azure AD ハイブリッド ID
ソリューションで再利用できる
Azure AD でシングル サインオン!! ~フェデレーション編~
特権ロールが必要になったとき、利用者側の要求に従って、特定の時間だけ特権ロールを付与することができる
Azure AD Privileged Identity Management とは
Privileged Identity Management (PIM) は、お客様の組織内の重要なリソースへのアクセスを管理、制御、監視することができる
Privileged Identity Management で拒否された Azure リソースへのアクセスのトラブルシューティング
Privileged Identity Management サービスから Azure リソースへのアクセスができるようにするには、Azure サブスクリプションで MS-PIM サービス プリンシパルにユーザー アクセス管理者ロールが常に割り当てられている必要があります。
1.1.4. Azure AD Pricileged Identity Management
PIMの主な機能の確認
・
JIT(Just-In-Time)によって、作業時のみ権限を割り当てる。これは0.5~24時間まで
・
リソースへの期限付きアクセス(権限を割り当てる際にあらかじめ有効期間を設定する)
・
その権限を有効にするための承認プロセス
・
特権アカウントを使用する際に、MFAを確実に使用(全ユーザーがMFAを使用している場合<すでにMFAにてログインしている>は再度サインインする必要なし)
・
そのアカウントのロールが必要な理由を明確化する。これによって、監査が容易になります。
・
特権アカウントが割り当てられた際の通知
・
アクセスレビューによる、特権アカウントの割り当て把握
・
監査履歴をしようすることで、PIMイベントを継続的に追跡可能。外部監査にも利用できる。
Azure AD グループ + PIM で特権ロールを管理してみた!
Privileged Identity Management (PIM) を使って Azure の権限管理をやってみた
主な特徴としては、特権ロールが必要ないときは、利用者に必要最低限のロールを付与しておき、特権ロールが必要になったとき、利用者側の要求に従って、特定の時間だけ特権ロールを付与することができます。管理者は能動的に利用者に権限付与をするのではなく、利用者からの要求に従って、必要な時間だけ必要な特権ロールを付与することができるようになります。
普段使いのロールを割当てる際には「Active」タイプのロールを割当てて、
特権ロールに関しては「Eligible」で割当てる(特権ロールを申請する資格がある)
Azure AD Privileged Identity Management で管理者権限の利用を制御する
Privileged Identity Management で Azure AD ロールの設定を構成する
Azure AD ロールの PIM
ロール設定を管理するには、グローバル管理者または特権ロール管理者ロールが必要です。
ロール設定は、ロールごとに定義されます。
同じロールに対するすべての割り当ては、同じロール設定に従います。
あるロールのロール設定は、別のロールのロール設定とは独立しています。
ロールの割り当てのアクティブ化要求が、有効期限が切れるまでアクティブなままである最大時間 (時間単位)
Azure AD Privileged Identity Management で管理者権限の利用を制御する
Azure AD Privileged Identity Management で管理者権限の利用を制御する
この種類のロールを割当てられたユーザーは、
アクティベーションの操作を必要とせずに、そのロールが常にアクティブ化される。
この種類のロールを割当てられたユーザーは、
そのロールをアクティベートする資格を有しており、
アクティベートすることによって、最大24時間そのロールをアクティブ化することができる。
ユーザーが有資格の割り当てを持っている場合は、ロールを使用する前にロールの割り当てをアクティブにする必要がある
ロールをアクティブにするには、ユーザーは最大範囲
(管理者が設定)
内で特定のアクティブ化期間と、アクティブ化要求の理由を選択する
申請者はAzure
Portalから特権ロールを申請(アクティブ化)します。
※申請者は申請する資格を有する、つまり該当ロールがEligibleタイプで割り当てられていることが前提条件です。
ロールの割り当てをアクティブ化するために多要素認証を要求するには、 Edit role setting の アクティブ化 タブで On activation, require Azure MFA を選択
Azure AD Privileged Identity Management で管理者権限の利用を制御する
承認者は自分自身のロールのアクティブ化要求を承認できません。
Privileged Identity Management に特権アクセス グループ (プレビュー) を持ち込む
Azure AD でロールを割り当て可能なグループを作成できます。
グループを Privileged Identity Management
で管理するには、
グループの所有者のロール、または
グローバル管理者のロール、または
特権ロール管理者のロール
に設定されている必要があります。
Privileged Identity Management で Azure AD ロールに対するセキュリティ アラートを構成する
Identity Governanceは、「適切なユーザーに」 「適切なアクセス権を」 「適切な期間のみ」 を実現するもの
Microsoft 365
を利用するにあたり、グループメンバーの管理やアプリケーション連携、管理者ロールの割り当て変更など、様々な管理業務が定期的に発生
日々適切な管理ができていれば問題ないが、完全自動化されていない限り、
うっかり権限を変更しないまま運用したり、所属しているグループのメンバーが把握しきれていない状態になったりしてしまう可能性もある。
過剰な権限を与えたままでは、資格情報の流出による
Microsoft 365
への侵入などのリスクも考えられる
管理者は、不必要な権限を削除し、適切なグループ管理を行うよう、適宜確認して運用することが望ましい
「アクセス
レビュー」は、所謂「棚卸し」の機能で、グループやアプリに対するユーザーのアクセス状況が確認できる
不要なメンバーや権限を効率的に削除することが可能
「アクセスレビュー」で、グループやアプリ、管理者ロールを効率的に管理
Azure AD でグループとアプリケーションのアクセス レビューを作成する
PIM で Azure リソース ロールと Azure AD ロールのアクセス レビューを作成する
Azure AD でグループとアプリケーションのアクセス レビューを作成する
Microsoft Entra アクセス レビューの展開を計画する
誰がレビューを行うかは、アクセス
レビューの作成者が作成時に決定します。
この設定は、レビューが開始した後は変更できません。
‣リソースのビジネス オーナーであるリソース所有者。
‣アクセス
レビューの管理者によって個別に選択された委任。
‣継続的なアクセスの必要性を各自で自己証明するユーザー。
‣マネージャーは、直属の部下によるリソースへのアクセスをレビューします。
[レビュー担当者を選択する] セクションで、アクセス
レビューを実行する人を 1 人以上選択します。
次の項目から選択できます。
- グループ所有者
(チームまたはグループに対するレビューを実行する場合のみ使用可能)
-
Selected user(s) or groups(s) (選択したユーザーまたはグループ)
-
Users review own access (ユーザーが自分のアクセスを確認する)
-
(プレビュー) Managers of users (ユーザーの管理者)。 Managers of users または [グループ所有者]
を選択した場合は、フォールバック
レビュー担当者を指定することもできます。 フォールバック
レビュー担当者は、そのユーザーの管理者がディレクトリで指定されていないか、またはそのグループに所有者がいない場合にレビューを実行するよう求められます。
条件付きアクセスとは、Azure AD への認証に対して、制限対象
(割り当て)に該当するユーザーを許可 or 拒否
(アクセス制御)する事ができる機能です。
これは、Azure AD
の「認証」と「認可」に対して、アクセス条件を追加する機能です。
Azure AD の条件付きアクセスの設定手順は次のとおりです。
1.Azure
portal
に、条件付きアクセス管理者、セキュリティ管理者、または全体管理者としてサインインします。
2.[Azure
Active Directory][セキュリティ]条件付きアクセス
の順に移動します。
3.[新しいポリシー]
を選択します。
4.ポリシーに名前を付けます。
条件付きアクセス
ポリシーは、ユーザーがリソースにアクセスする場合に、ユーザーはアクションを完了する必要があるという
if-then ステートメント
例:
給与管理者は、給与処理アプリケーションにアクセスしようとする場合、多要素認証を実行することが要求される
CAのポイント
- CAポリシーに優先順位という概念はない
-
すべてのポリシーが評価され、割り当て条件に合致したサインインイベントに対し、制御がすべて適用される
-
許可よりもブロックが勝つ
【Azure】条件付きアクセスの設定方法解説!【ポータルへのアクセスをIPアドレスで制限する】
許可するIPアドレスの指定
「ネームド
ロケーション」>「新しい場所」
多要素認証
条件付きアクセスを利用することでユーザーが増えた場合でも、自動的にMFAを適用することが可能
多要素認証を要求されたら
条件付きアクセス
ポリシーの影響を評価するために使用できるモードです。
レポート専用モードでは、ポリシーが適用された場合にどのような結果になるかをレポートとして確認できますが、実際にはポリシーは強制されません。
管理者が環境で条件付きアクセス ポリシーを有効にする前に、その影響を評価することができる
Azure 認証方法ポリシーでは、ユーザーが Azure Active Directory (Azure AD) にサインインする際に使用できる認証方法を管理できる
Azure Active Directory のパスワードレス認証オプション
Windows Hello for Business
Microsoft Authenticator
FIDO2
セキュリティ キー
Azure Active Directory パスワード保護を使用して不適切なパスワードを排除する
ユーザーが自分のパスワードを変更またはリセットすると、
グローバルとカスタムの禁止パスワード
リストから結合された用語リストに対して新しいパスワードを検証することで、その強度と複雑さがチェックされます。
オンプレミスの Azure Active Directory パスワード保護を計画してデプロイする
現在のポリシーが監査モードに構成されている場合、“不正な” パスワードは、イベント ログ メッセージが生成される原因となりますが、処理されて更新されます。
強制モードが有効になっている場合は、ポリシーに従って安全でないと見なされたパスワードは拒否されます。
Azure Active Directory の多要素認証のデプロイを計画する
チュートリアル:Azure AD Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する
Azure AD Multi-Factor Authentication の設定を構成する
演習 - Azure AD Multi-Factor Authentication の有効化
Azure AD Multi-Factor Authentication におけるユーザーの状態
Azure Active Directory での統合されたセキュリティ情報の登録の概要
Azure Active Directory での統合されたセキュリティ情報の登録の有効化
統合された登録を有効にするには、次の手順に従います。
Azure portal
に ユーザー管理者 または 全体管理者 としてサインインします。
ユーザーは1回登録でMFAとSSPRの両方を利用できますか。
ユーザーは 1 回登録して Azure AD Multi-Factor Authentication
(MFA)とセルフサービス パスワード
リセット(SSPR)の両方の利用が可能です。
統合される前、ユーザーは Azure
AD Multi-Factor Authentication (MFA) とセルフサービス パスワード
リセット (SSPR)
の認証方法を別々に登録しましたが、2020年8月15日の以降は、すべての新しい
Azure AD テナントで、統合された登録が自動的に有効になりました。
Identity Protection を使用して組織内の ID のリスクを特定し、対処する
Azure AD Premium P2 ライセンスが必要
Identity Protection は Microsoft
が持つ脅威の検出ソリューションの一つで
Azure Advanced Threat
Protection や Microsoft Cloud App Security と連携し ID
に関するリスクを検出 /管理 / 保護することができます。
Azure AD Identity Protection をデプロイする
Azure AD Identity Protectionのリスク検出を試してみた
1.1.3. Azure AD Identity Protection
Identity Protection
では、ユーザーの標準的な行動であると確信できるものは何かを判断し、それを使用してユーザーのリスクに関する意思決定を行うことがでる
“ユーザー リスク” とは、ID が侵害されている 確率の計算
管理者は、このリスク
スコア信号に基づいて、組織の要件を適用するかどうかを決定できる
Identity Protection では、リスクを低、中、高の複数のレベルに分類
ポリシー作成の最初のステップとして、アラートをトリガーする Identity
Protection のレベルを選択する必要があります。
Microsoft
の推奨事項は、ユーザー ポリシーのしきい値を高に設定し、サインイン リスク
ポリシーを中以上に設定し、自己修復オプションを有効にすることです。
Azure Active Directory (Azure AD) の条件付きアクセスには、リスクへの対応を自動化し、リスクが検出されたときにユーザーが自己修復できるようにするために設定できる、2 種類のリスク ポリシーがあります。
割り当て で、 [ユーザーまたはワークロード ID]
を選択します。
Include で、 [すべてのユーザー]
を選択します。
[除外] で、 ユーザーとグループ
を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
Identity Protection 2 つのリスク ポリシーの導入メリットについて
不審なサインイン試行を識別して対処
Azure AD Multi-Factor
Authentication
を使用して追加の検証フォームを提供するようユーザーに求めることができます。
次のような要件を含むサインイン
リスクに基づいてアクセス制御を適用できます。
アクセスのブロック
アクセスを許可
多要素認証を要求する
注意
サインイン リスク ポリシーをトリガーする前に、ユーザーは
Azure AD Multifactor Authentication
に事前に登録しておく必要があります。
Azure ADのIdentity Protectionを設定する
「低以上」だと検知の頻度が多くなる可能性があるので、MS推奨は「中以上」です。
一般的な条件付きアクセス ポリシー: サインイン リスク ベースの多要素認証
このポリシーを構成できる場所は 2 つあります。1
つは条件付きアクセスで、もう 1 つは Identity Protection
です。
ユーザーが MFA
に登録されていない場合、危険なサインインがブロックされ、AADSTS53004
エラーが表示されます。
資格情報が侵害された可能性のあるユーザー
アカウントを識別して対処
ユーザーに新しいパスワードの作成を促すことができる
管理者は、
- アクセスをブロックする
- アクセスを許可する
-
アクセスを許可するが Azure AD のセルフサービス パスワード リセット
を使用してパスワードを変更する必要がある
ことを選択できます。
Azure ADのIdentity Protectionを設定する
ユーザーが Azure AD Multi-Factor Authentication
に登録されているかどうかを確認
サインイン リスク ポリシーによって
MFA を要求する場合は、ユーザーが Azure AD Multi-Factor Authentication
に既に登録されている必要がある
危険なユーザー
レポートによって提供される情報を使用して、管理者は、以下を見つけることができる
-
どのユーザーにリスクがあり、リスクが修復されたか無視されたか
-
検出の詳細
- すべての危険なサインインの履歴
-
リスクの履歴
管理者は、これらのイベントに対するアクションを選ぶことができる
-
ユーザー パスワードをリセットする
- ユーザーの侵害を確認する
-
ユーザー リスクを無視する
-
ユーザーによるサインインをブロックする
- Azure ATP
を使用してさらに調査する
Azure Active Directory でのアプリケーション管理とは
Azure
ADのアプリケーション管理は、クラウドでアプリケーションを作成、構成、管理、および監視するプロセスです。
アプリケーションが
Azure AD
テナントに登録されると、そのアプリケーションに割り当てられているユーザーは安全にアクセスできます。
さまざまな種類のアプリケーションを
Azure AD に登録できます。
Microsoft ID プラットフォームにおける OAuth 2.0 と OpenID Connect (OIDC)
Microsoft ID プラットフォームと OAuth 2.0 認証コード フロー
Microsoft ID プラットフォームと暗黙的な許可のフロー
OAuth 2.0 コード付与フローを使用して Azure Active Directory Web アプリケーションへアクセスを承認する
Azure Active Directory のアプリケーション オブジェクトとサービス プリンシパル オブジェクト
ID とアクセスの管理機能を Azure AD に委任するには、アプリケーションを
Azure AD のテナントに登録する必要がある
アプリケーションを Azure AD
に登録するときに、アプリケーションの ID 構成を作成する。これによって
Azure AD との連携が可能となる。
Azure portal
でアプリを登録するときに、それがシングル
テナントかマルチテナントかを選択し、必要に応じて リダイレクト
URI を設定する。
ポータルでアプリケーションを登録すると、ホーム テナント に
アプリケーション オブジェクト と サービス プリンシパル オブジェクト が
自動的に 作成される。
Microsoft Graph API
を使用してアプリケーションを登録または作成する場合、サービス
プリンシパル オブジェクトの作成は別の手順。
アプリケーションは、Azure AD が提供するサービスを利用するために Azure AD に登録される
Azure Active Directory の [ユーザー設定] で、「ユーザーはアプリケーションを登録できる」を「いいえ」に変更することによって、一般ユーザーによるアプリの登録を行えなくすることが可能
AzureADに作成したアプリケーションのID・パスワードの認証を委任することができる機能
Azure Active Directory のエンタープライズ アプリケーション所有権の概要
ユーザーがクライアント アプリケーションにサインインしています。
クライアント
アプリケーションは、ユーザーの代わりにリソースにアクセスします。
委任アクセスでは、委任されたアクセス許可が必要です。
ユーザーがサインインしていない状態でアプリケーションが単独で動作します
アプリケーションにアプリ
ロールを割り当てるときは、“アプリケーションのアクセス許可”
を作成します。
通常、アプリケーションのアクセス許可は、認証および承認された API
呼び出しをユーザーによる操作なしで行う必要がある、デーモン
アプリまたはバックエンド サービスによって使用されます。
Microsoft Graph にアクセスするためのアクセス許可を追加する
アプリケーションにアクセス権を付与することを、リソース所有者が “承認”する
Azure Active Directory におけるユーザーと管理者の同意
管理者の同意ワークフローを有効にするには、グローバル管理者である必要があります
アプリケーションに対してテナント全体の管理者の同意を付与する
グローバル管理者または特権ロール管理者:任意の API
に対してアクセス許可を要求するアプリに同意を付与
クラウド
アプリケーション管理者またはアプリケーション管理者:任意の API
に対してアクセス許可を要求するアプリに同意を付与
アプリケーションにユーザーを割り当てると、そのアプリケーションが、簡単にアクセスできるようにユーザーの
マイ アプリ ポータルに表示されます。
アプリケーションでアプリ
ロールが公開されている場合は、ユーザーに特定のアプリ
ロールを割り当てることもできます。
グループをアプリケーションに割り当てると、そのグループ内のユーザーのみがアクセスできるようになります。
割り当ては、入れ子になったグループにはカスケードされません。
グループベースの割り当てには、Azure Active Directory Premium P1
または P2 エディションが必要です。
グループ
ベースの割り当てがサポートされるのはセキュリティ グループのみです。
入れ子になったグループ メンバーシップと Microsoft 365
グループは、現在サポートされていません。
マイ アプリは、Azure Active Directory (Azure AD)
でアプリケーションを管理および起動するために使用される Web
ベースのポータル
マイ アプリでアプリケーションを操作するには、Azure
AD の組織アカウントを使用し、Azure
AD管理者によって付与されるアクセス権を取得
Azure AD でユーザーをアプリケーションに割り当てる方法
管理者が [アプリケーションのセルフ サービス アクセス] を有効にして、ビジネス承認なしでユーザーがマイ アプリの [アプリの追加] 機能を使用してアプリケーションを追加することを許可します
アクセス権は、テナント
レベルで付与したり、特定のユーザーに割り当てたり、セルフサービス
アクセス から付与したりできます。
ユーザーが マイ
アプリ ポータル
から自分でアプリケーションを見つけられるようにするには、Azure portal で
セルフサービス アプリケーション アクセスを有効
にします。
従業員エンパワーメントを促進してヘルプ デスク問い合わせを減らす
マイ アプリ ポータルは、Azure Active Directory (Azure AD) のマイ
アプリと呼ばれるWebベースのポータルで、アプリの起動と管理を行うために使用されます。
このページを使用すると、ユーザーは1か所で作業を開始し、アクセスできるすべてのアプリケーションを見つけることができます。
SAML トークン暗号化は、ID プロバイダーとサービス
プロバイダー間で認証および認可データを交換するためのオープン標準である
Security Assertion Markup Language (SAML) を使用して、Azure AD
が発行する SAML トークンを暗号化する機能
SAML
トークン暗号化を構成するには、次の手順が必要です。
-
アプリケーションで構成されている秘密キーに一致する公開キー証明書を取得します。
-
Azure AD のアプリケーション構成に証明書を追加します。
-
アプリケーションの SAML 設定でトークン暗号化を有効にします。
Azure Active Directory の SAML トークン暗号化を構成する
トークン暗号化を構成するには、公開キーを含んだ X.509 証明書ファイルを、アプリケーションを表す Azure AD アプリケーション オブジェクトにアップロードする必要があります。
マネージド ID は、さまざまなソフトウェア
コンポーネント間の通信を保護するために使用されるシークレット/資格情報の管理に関して開発者が直面した課題に対応して作成されました。
マネージド
ID
により、開発者が資格情報を手動で管理する必要がなくなります。
マネージド
ID は、アプリケーションが Azure AD
認証をサポートする任意のリソースに接続するために使用できる ID です。
ざっくり覚える、Azureサービス プリンシパルとマネージド ID
Azure によって提供される認証ツールは2つある
1)サービス
プリンシパル
2)マネージド
ID
2つともの機能的にはだいたい同じ。
サービスプリンシパルは、初期設定や情報管理の運用がめんどいので、Azure内の認証ツールは基本、簡単発行・運用ができるマネージドID利用が推奨。
マネージドID
は、「オンプレミスのアプリケーション または サービス」
は未サポートなので、オンプレミス利用時はサービスプリンシパルを使わざるえない
Azure PowerShell で自動化する時に使用する Identity について
Azure の一部のサービスでは、そのサービス インスタンスでマネージド ID
を直接有効にするオプションが提供されます。
有効にするとすぐにシステムによって割り当てられたマネージド
ID の場合、別の ID が AAD で作成され、サービス インスタンスのライフ
サイクルにリンクされます。
その特定の ID を使用して AAD
からトークンを要求できるのは、その Azure リソースだけです。
ユーザー割り当てマネージド ID
は、それを使用するリソースとは別に管理されます。
この分離により、この
ID を Azure サービスの複数のインスタンスに割り当てることができます。
例えば、
マネージド ID (ClientId = 1234) に StorageAccount7755
への読み取りおよび書き込みアクセス許可が付与され、LogicApp3388
に割り当てられている場合、
マネージド ID やストレージ
アカウントに対する直接的な権限は持たないが、LogicApp3388
内でコードを実行する権限を持つ Alice は、そのマネージド ID
を使用するコードを実行することで、StorageAccount7755
との間でデータの読み取りと書き込みを行うこともできます。
Azure AD を使用して Azure の Windows 仮想マシンにログインする
Azure AD 資格情報を使用して VM にログインするには、最初に VM
のロールの割り当てを構成する必要があります。
VM
にログインできるユーザーを決定する Azure RBAC
ポリシーを構成する必要があります。
VM
へのログインを承認するには、次の 2 つの Azure
ロールが使用されます。
- 仮想マシンの管理者ログイン:
このロールを割り当てられたユーザーは、管理者特権を持つユーザーとして
Azure 仮想マシンにログインできます。
- 仮想マシンのユーザー ログイン:
このロールが割り当てられたユーザーは
正規ユーザーの権限を持つユーザーとして Azure
仮想マシンにログインできます。
注意
仮想マシンの管理者ログインと仮想マシンのユーザー
ログインのロールは、dataActions
を使用しているため、管理グループのスコープで割り当てることはできません。
現時点では、これらのロールは、サブスクリプション、リソース
グループまたはリソース スコープでのみ割り当てることができます。
Azure Active Directory Domain Services とは
Azure AD アプリケーション プロキシとは、オンプレミスの Web
アプリケーションにリモートからアクセスできるようにする Azure AD
の機能です。
Azure portal で構成し、外部のパブリック URL
を発行して内部のアプリケーション サーバーに接続します。
VPN
やリバース プロキシに代わるもので、ローミング (リモート)
ユーザー向けです
Azure AD アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する
管理グループを使うと、サブスクリプションの種類に関係なく、大きな規模でエンタープライズ レベルの管理を行うことができる
各ディレクトリには、ルート管理グループと呼ばれる 1 つの最上位管理グループがある
Azure ロールベースのアクセス制御 (Azure RBAC) とは
Azure Active Directory のロールベースのアクセス制御の概要
RBAC(ロールベースアクセス制御)とは?Azureを安全に利用するための権限管理
緑:Azure ADに対するロール
青:Azureリソースに対するロール
※[サブスク][リソースグループ][リソース]含む
赤:サブスクリプションのみに対するロール
※(旧)RBAC
※RBACの有効範囲は、青(赤含む)の範囲になります。
Azure VM や Azure Storage などの、各種リソースへのアクセス権限を割り当てる
コンピューティングやストレージなどの Azure
リソースに対するきめ細かなアクセス管理を提供する
Azure Resource
Manager 上に構築された承認システム
Azure ロール、Azure AD ロール、従来のサブスクリプション管理者ロール
ロール定義はアクセス許可のコレクションです。
単にロールと呼ばれることもあります。
ロール定義では、実行できるアクション (読み取り、書き込み、削除など)
が一覧表示されます。
許可されるアクション、あるいは基となるデータに関連するアクションから除外されるアクションを一覧表示することもできます。
NotActions アクセス許可では、許可される Actions (ワイルドカード (*) を使用) から取り除く (除外する) コントロール プレーン アクションを指定
NotActions
でアクションを除外するロールをユーザーに割り当てたうえで、同じアクションへのアクセス権を付与する
2
番目のロールを割り当てた場合、
ユーザーはそのアクションの実行が許可されます。
NotActions
は拒否ルールとは異なり、特定のアクションを除外する必要があるときに、許可されるアクションのセットを作成するのに便利な方法にすぎません。
Alice はサブスクリプション
スコープで所有者ロールに割り当てられています。
Alice
のサブスクリプション スコープにはワイルドカード (*)
アクションがあるため、そのアクセス許可が継承され、すべてのコントロール
プレーン アクションを実行できます。
Alice
は、コンテナーの読み取り、書き込み、および削除を行うことができます。
しかし、Alice
は追加の手順を行わずにデータ プレーン
アクションを実行することはできません。
たとえば、既定では、Alice
はコンテナー内の BLOB を読み取ることができません。
BLOB
を読み取るには、Alice はストレージ アクセス キーを取得し、それを使用して
BLOB にアクセスする必要があります。
ロール定義を割り当てることができるスコープを指定します。
(ルート、管理グループ、サブスクリプション、またはリソース グループ)
カスタム
ロールを必要とする管理グループ、サブスクリプション、またはリソース
グループのみで、その割り当てを利用できるようにすることができます。
少なくとも 1 つの管理グループ、サブスクリプション、またはリソース
グループを使用する必要があります。
Azure RBAC
でロールを割り当てる権限を含め、すべてのリソースを管理するためのフル
アクセスを付与
Actions
“*“
DataActions
”なし”
すべての種類の Azure
リソースを作成および管理できる
他のユーザーにアクセス権を割り当てたり、削除したりすることはできない
リソースに対するユーザーアクセスを管理
仮想マシンの作成と管理、ディスクの管理、ソフトウェアのインストールと実行、VM 拡張機能を使用した仮想マシンのルート ユーザーのパスワードのリセット、VM 拡張機能を使用したローカル ユーザー アカウントの管理
Virtual Machine Administrator Login
ポータルで仮想マシンを表示し、管理者としてログインできる
ネットワークを管理できます。ただし、それらへのアクセスは含まれません。
Microsoft Defender for Cloud のアクセス許可を表示および更新します。
セキュリティ閲覧者と同じアクセス許可があり、セキュリティ
ポリシーの更新、アラートと推奨事項の無視も可能になります。
ユーザー割り当て ID の作成、読み取り、更新、削除
カスタム ロールは、ユーザー、グループ、サービス プリンシパルに対して、管理グループ (プレビューのみ)、サブスクリプション、およびリソース グループのスコープで割り当てることができます
Azure PowerShell を使用して Azure カスタム ロールを作成または更新する
Azure portal を使用して Azure カスタム ロールを作成または更新する
カスタム ロールの作成を開始するには、次の 3
つの方法
・ロールを複製
・最初から行う
・JSON から始める
カスタム ロールを割り当て可能にするサブスクリプションまたはリソース
グループを開き、 [アクセス制御 (IAM)] を開きます。
[追加]
をクリックし、 [カスタム ロールの追加] をクリックします。
1.Azure portal で、カスタム
ロールを割り当て可能にするサブスクリプションまたはリソース
グループを開き、 [アクセス制御 (IAM)] を開きます。
⒉.[ロール]
タブをクリックして、すべての組み込みおよびカスタム
ロールの一覧を表示
複製するロールを検索
Azure リソース プロバイダーは、Azure サービスの機能を提供する REST 操作のコレクション
Azure サービス:Application Gateway、Azure Bastion、Azure DDoS Protection、Azure DNS、Azure ExpressRoute、Azure Firewall, Azure Front Door Service、Azure Private Link、Load Balancer、Network Watcher、Traffic Manager、Virtual Network、Virtual WAN、VPN Gateway
Microsoft.Web/sites/start/Action Web アプリを起動
手順 1:アクセスが必要なユーザーを決定する
手順
2:適切なロールを選択する
手順 3:必要なスコープを特定する
手順 4.
前提条件を確認する
手順 5. ロールを割り当てる
Azure RBACでAzureリソースへのアクセス権を管理する
※今回は仮想マシン共同作成者ロールをユーザーに付与
1. Azure
Portalで、アクセス制御を設定するスコープを表示 (今回は仮想マシン)
Azure RBAC は加算方式のモデルであるため、自分で行ったロール割り当ての合計が自分の実際のアクセス許可になる
ユーザーにサブスクリプション スコープの共同作成者ロールとリソース
グループの閲覧者ロールが付与されている例
共同作成者アクセス許可と閲覧者アクセス許可を足すと、実質的にサブスクリプションの共同作成者ロールになる
“スコープ” は、アクセスが適用されるリソースのセット
4つのレベル
(管理グループ、サブスクリプション、リソース グループ、リソース)
でスコープを指定できます。
Azure サブスクリプションを別の Azure AD ディレクトリに移転する
MOSP Azure サブスクリプションの課金所有権を別のアカウントに譲渡する
サブスクリプションを別の Azure AD テナント アカウントに譲渡する
サブスクリプションの課金所有権を別の Azure AD テナントのアカウントに譲渡する場合は、サブスクリプションを新しいアカウントのテナントに移動できる
Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる
リソースはこうあるべきだ/こうなってはいけない、を定義して監視します。
Azure Policy を使用してリソースを制御および監査する
【AZ-900】Azure Policyとは?具体例を交えてわかりやすく解説!
Azure
Policyは、Azureリソースを組織のルールに沿った状態に保つための仕組み
-
ルールに沿ったリソースの作成を強制
-
ルール違反のリソースがあればお知らせ(監査)
イニシアティブまたはポリシーを作成する際には、定義の場所を指定する必要があります。
定義の場所は、管理グループまたはサブスクリプションにする必要があります。
この場所によって、イニシアティブまたはポリシー定義を割り当てることができるスコープが決まります。
リソースは、割り当て対象とする定義の場所の
ダイレクトメンバー
か、その階層内の子である必要があります。
サブスクリプションの場合
-
そのサブスクリプション内のリソースだけをポリシー定義に割り当てることができます。
管理グループの場合
-
子管理グループと子サブスクリプション内のリソースだけをポリシー定義に割り当てることができます。
ポリシー定義を複数のサブスクリプションに適用する予定がある場合、その場所は各サブスクリプションを含む管理グループである必要があります。
Azure Virtual Machines 用の Azure Policy 組み込み定義
Microsoft Defender for CloudのAzure Policy組み込み定義
Azure Policy / Effect 効果を整理する (AuditIfNotExits / DeployIfNotExits)
Azure Policy が条件にマッチした際に、どのような行動を起こすのかを定義するのが effect です。
ポリシー効果ごとの評価タイミング
ポリシーの評価がいつ行われるかですが、基本的にはリソースのデプロイ時に評価されます1。
ここで、デプロイというのは、新規作成も変更もどちらも含みます。
このように、効果によって評価されるタイミングが異なります。
なかでもIfNotExistsの2つはピンとこないかもしれません。これのキモは、いま直接デプロイしているリソースではないリソースも含めた評価をしたいときに使えることです。
Deny は、ポリシーを通して定義された基準に一致していないために失敗するリソース要求を防ぐために使用されます
非準拠のリソースが評価された場合、Audit を使用してアクティビティ ログに警告イベントが作成されますが、要求は停止されません
DeployIfNotExists
ポリシー定義は条件が満たされたときにテンプレートのデプロイを実行します。
DeployIfNotExists
として設定された有効なポリシー割り当てには、修復を行うための マネージド
ID が必要
DeployIfNotExists は、リソース
プロバイダーによって、サブスクリプションまたはリソースの作成または更新要求が処理され、成功を示す状態コードが返されてから、
構成可能な遅延後に実行されます。
関連するリソースがない場合、または ExistenceCondition
によって定義されたリソースが true
と評価されない場合、テンプレートのデプロイが発生します。
デプロイの時間は、テンプレートに含まれるリソースの複雑さによって異なります。
イニシアティブを使用すると、複数の関連するポリシー定義をグループ化できます。
グループを単一の項目として操作するので、割り当てと管理が単純になります。
それぞれのポリシーを個別に割り当てるのではなく、イニシアティブを適用することになります。
Azure Policy
のイニシアティブは、関連するポリシーをまとめてグループ化する手段です。
イニシアティブ定義には、大きな目標に対するコンプライアンスの状態を追跡するのに役立つすべてのポリシー定義が含まれます。
“スコープ” という用語は、ポリシー定義が割り当てられる、すべてのリソース、リソース グループ、サブスクリプション、または管理グループのことを指します。
チュートリアル:コンプライアンスを強制するポリシーの作成と管理
【AZ-900】Azure Policyとは?具体例を交えてわかりやすく解説!
割り当て済みの定義は「割り当て」のメニューから確認できます
イニシアティブまたはポリシー定義が割り当てられ、評価されると、ポリシー ルールの条件とそれらの要件に対するリソースの準拠に基づいて、結果のコンプライアンス状態が決定される
【AZ-900】Azure Policyとは?具体例を交えてわかりやすく解説!
Azure Policyのルールが守られているかどうか(準拠状況)は「概要」や「コンプライアンス」のメニューから確認できます。
Azure Policy を使って準拠していないリソースを修復する
deployIfNotExists や modify の効果を含むポリシーに準拠していないリソースは、修復 を使って準拠状態にすることができる
deployIfNotExists ポリシーの評価時に Azure Policy
によりテンプレートのデプロイが開始される場合、
またはmodify
ポリシーの評価時にリソースが変更される場合には、
これらの操作にはポリシーの割り当てに関連付けられているマネージド
ID が使用されます。
ポリシーの割り当てでは、Azure
リソースの承認にマネージド ID が使用されます。
ブループリントは、さまざまな リソーステンプレート
やその他のアーティファクトのデプロイを宣言によって調整する手法
-
ロールの割り当て
- ポリシーの割り当て
- Azure Resource Manager
テンプレート (ARM テンプレート)
- リソース グループ
PowerShell を使用した Azure Blueprints の管理
Azure Blueprints は、Azure
ガバナンスのための「ワンストップショップ」を提供します。
JSON
テンプレートとコントロールされた統合ワークフローを実装することによって、標準化された
Azure 環境を定義、デプロイ、実施、および維持できます。
ブループリント定義を作成するとき、ブループリントの保存場所を定義します。
ブループリントは、自分が共同作成者のアクセス権を持っている管理グループまたはサブスクリプションに保存できます。
保存場所が管理グループである場合、その管理グループのすべての子サブスクリプションへの割り当てにブループリントを使用できます。
Azure Blueprint でのリソース ロックについて
チュートリアル:Azure Blueprints のリソース ロックを使用して新しいリソースを保護する
ブループリント割り当てに適用されるロック モードには、次に示す 3
つのオプションがあります。
ロックしない、読み取り専用、削除しない。
編集/削除できません
リソース
グループは読み取り専用であり、リソース
グループ上のタグを変更することはできません。 このリソース
グループに対しては、ロックなしリソースの追加、移動、変更、削除を行うことができます。
読み取り専用
いかなる方法でもリソースを変更することはできません。
変更することも削除することもできません。
ブループリント割り当て内のアーティファクトによって作成されたリソースは、次の 4 つのいずれかの状態になります。ロックなし、読み取り専用、編集/削除できません、または削除不可。 各種のアーティファクトは、ロックなしの状態にすることができます。
リソース グループは読み取り専用であり、リソース グループ上のタグを変更することはできません。 このリソース グループに対しては、ロックなしリソースの追加、移動、変更、削除を行うことができます。
https://az-start.com/azure-monitor-overview/
すべての新しい仮想マシン、スケール セット、オンプレミス サーバーに Azure Monitor エージェントをデプロイして、サポートされているサービスと機能のデータを収集します
Azure Monitor のエージェント用の Resource Manager テンプレートのサンプル
Azure の Windows 仮想マシンおよび Linux 仮想マシンにレガシ Log Analytics エージェントをインストールして、Log Analytics ワークスペースにそれを接続
Microsoft Sentinel のデプロイで Log Analytics エージェントを使用している場合は、AMA への移行の計画を開始することをお勧めします
Azure Monitor のエージェント用の Resource Manager テンプレートのサンプル
Azure の Windows 仮想マシンおよび Linux 仮想マシンにレガシ Log
Analytics エージェントをインストールして、Log Analytics
ワークスペースにそれを接続
これは、Azure Log Analytics
仮想マシン拡張機能を有効にすることで実現される
https://learn.microsoft.com/ja-jp/azure/virtual-machines/extensions/oms-windows
Azure Monitor
ログでは、クラウドとオンプレミスの資産全体にわたって監視機能を提供します。
Windows 用の Log Analytics
エージェント仮想マシン拡張機能は、Microsoft
によって発行およびサポートされています。
この拡張機能では、Azure
仮想マシンに Log Analytics
エージェントがインストールされ、仮想マシンが既存の Log Analytics
ワークスペースに登録されます。
この拡張機能では、ターゲット Log Analytics ワークスペースのワークスペース ID とワークスペース キーが必要です。
Log Analytics ワークスペースは、Azure Monitor、Microsoft Sentinel や
Microsoft Defender for Cloud などの他の Azure サービスからの
ログデータ用の固有の環境です。
各ワークスペースには、複数のデータ行を含む別々の列に編成された複数のテーブルが含まれています。
テーブル内の各データは、指定された期間保持され、その後は削除されるか、より少ない保持料金でアーカイブされます。
Log Analytics ワークスペースは、
Azure Monitor、および Microsoft
Sentinel や Microsoft Defender for Cloud などの他の Azure
サービスからのログ データのための固有の環境です。
ログとデータを収集すると、情報はワークスペースに保存されます。
#ワークスペースには、一意のワークスペース ID とリソース ID
があります。
#ワークスペース名は、指定したリソース
グループ内で一意である必要があります。
ワークスペースを作成したら、データ
ソースとソリューションのデータをそこに保存するように構成します。
Azure Monitor ログは Azure Data Explorer を基盤としており、ログ クエリは同じ Kusto 照会言語 (KQL) を使って作成します。
Log Analytics ワークスペースのテーブルを管理する
リソースの種類別に整理された Azure Monitor ログ テーブルリファレンス
Azure Diagnostics モードを使用する Azure サービスのリソース ログが格納されます
共通イベント形式のイベントを収集するためのもの
Azure Security Center または Azure Sentinel によって Windows マシンから収集されるセキュリティ イベント
セキュリティ製品によって生成されたアラート
Azure ポータルから Log Analytics ワークスペースの テーブルごとに 保管期間・Basic/Archive を設定する
Azure Monitor ログ クエリでのコンピューター グループ
コンピューター グループを使用して、ログ クエリの範囲を特定のコンピューターのセットに限定することができる
Azure Monitor アラートとは、 Azure Monitor
で監視しているインフラストラクチャ・アプリケーション内のデータの状態をユーザーに通知する機能のことです。
Azure Monitor
のデータプラットフォームでは、任意のメトリック・ログデータに対してアラートを生成できます。
Azure Monitorアラートとは?特徴や利用するメリットを解説
アクション グループとは、どの宛先の電子メールに送信するか、どの function を呼び出す、などの通知方法を定義したもの
Azure Monitor アクション グループを使用すると 、アラートがトリガーされたときに実行するアクション の一覧を定義できます
Azure Portal でのアクション グループの作成および管理
Azure Monitor
のデータによって、インフラストラクチャまたはアプリケーションに問題がある可能性があることが示されると、アラートがトリガーされます。
Azure Monitor、Azure Service Health、Azure Advisor は、アクション
グループ
を使用して、アラートについてユーザーに通知し、アクションを実行します。
アクション グループは、Azure
サブスクリプションの所有者によって定義された通知設定のコレクションです。
[Azure Monitor] アクション グループについて
Azure
Monitorのアラートルールを作成する際、ディメンションで分割することができます。
これにより、複数のAzureリソースで同じ条件を監視するために、数値または文字列の列の組み合わせをグループ化することによってアラートが個別のアラートに分割されます1。
また、1つのメトリックアラートルールで、メトリックの複数の次元値を監視することもできます。
メトリックのディメンションとは、メトリックの値を記述するためにより多くのデータを保持する名前と値のペアです
リソース メトリックの条件を定期的に評価することで、リソースを監視
Azure Monitorのアラート処理ルールを使って非監視設定(アラート抑止)
アラート処理ルールはスコープ(リソース)を指定して設定する
アラート処理は適用するスコープ(リソース)を指定して設定します。
例えば特定の仮想マシンやリソースグループに対しての適用になります。
アラートルールではなくリソース指定での指定になります。
アラート処理ルールで出来る事は2つ
アラート処理ルールで出来る事は2つになります。
-
抑制
アラートの発動を停止する
- アクション
グループの適用
特定のスコープに対してアクショングループを適用する
サブスクリプションにあるAzureリソースに対して行われた書き込み操作(作成・変更・削除)を記録したログ
アクティビティ ログの各イベントには、特定のカテゴリがある
このカテゴリには、Resource Manager
で実行されるすべての作成、更新、削除、アクション操作のレコードが含まれています。
このカテゴリで表示されるイベントの種類として、“仮想マシンの作成”、“ネットワーク
セキュリティ グループの削除” などがあります。
Microsoft Defender for Cloud
によって生成されたアラートのレコードが含まれます。
セキュリティ
イベントの例としては、“Suspicious double extension file executed”
(疑わしい二重拡張子ファイルが実行されました) があります。
Azure リソース内 (データ プレーン) で実行された操作の分析情報を提供します。 たとえば、キー コンテナーからのシークレットの取得や、データベースへの要求などです。 リソース ログの内容は、Azure サービスとリソースの種類によって異なります。
サインイン アクティビティの履歴と、特定のテナントに対して Azure AD で行われた変更の監査証跡が含まれます。
インストルメント化されたアプリケーション コードからデータを収集し、アプリケーションのアクティビティ、パフォーマンス、カスタム メトリック、および例外を追跡する、テレメトリ フレームワーク
ソフトウェアやアプリケーションがパフォーマンス改善や品質向上を目的として収集するユーザーの利用状況データのこと
Application Insights Telemetry のデータ モデル
Application Insights
は、アプリケーションのパフォーマンスと使用状況を分析できるように、Web
アプリケーションから Azure portal にテレメトリを送信します。
テレメトリ
モデルを標準化して、プラットフォームと言語に依存しない監視を作成できます。
Microsoft Defender for Servers
を有効にすると、次の機能が自動的に利用可能になります。
-
サポートされているバージョンの Windows および Linux の脅威検出
-
ファイルの整合性の監視
- ジャストインタイムの VM アクセス
- Qualys
または Threat and Vulnerability Management (TVM)
のいずれかを展開するオプションを備えた統合された脆弱性評価
-
適応型アプリケーション制御
- 適応型ネットワークの強化
-
ネットワーク マップ
- 規制順守ダッシュボード
Microsoft Defender for Cloud とは
Microsoft Defender for Cloud
は、リソースのセキュリティを可視化して制御することで、脅威の防止、検出、対応を行うのに役立ちます。
これにより、サブスクリプション全体に統合セキュリティの監視とポリシーの管理を提供し、気付かない可能性がある脅威を検出し、セキュリティ
ソリューションの広範なエコシステムと連動
Microsoft Defender for Cloud とは
Azure、オンプレミス、マルチクラウド (Amazon AWS および Google GCP) のすべてのリソースに対するクラウド セキュリティ態勢管理 (CSPM) と クラウド ワークロード保護プラットフォーム (CWPP)
Microsoft Defender for Cloud によって監視される Azure リソースは何ですか?
Microsoft Defender for Cloudとは?~概要、メリット、コストを解説~
2021年に「Azure Security Center」と「Azure Defender」が名称を変更して「Microsoft Defender for Cloud」となりました。
[Azure] Security Center の 8 つの機能について数行にまとめてみた
Azure セキュリティ
ポリシーは、Azureのリソースに対してのポリシーを定義し、各リソースがセキュリティ要件に準拠するようにするためのもの
Azure
Policy で作成される Azure
ポリシー定義は、制御する特定のセキュリティ条件に関するルール
Defender
for cloud は、主に、特定の条件と構成を確認し、コンプライアンスを報告する
“監査” ポリシーを使用
セキュリティ設定を適用するために使用できる
“強制” ポリシーもある
Microsoft Defender for CloudのAzure Policy組み込み定義
イニシアチブグループには、「Defender for Cloud」 カテゴリに Azure
Policy イニシアチブ定義の一覧が表示されます
既定のイニシアティブ
グループには、Defender for Cloud の既定のイニシアティブである Microsoft
クラウド セキュリティ ベンチマークに含まれるすべての Azure Policy
定義の一覧が示されています
カテゴリグループには、「Defender for
Cloud」カテゴリにすべてのAzure Policy定義の一覧が表示されます
セキュリティ
イニシアチブは、特定の目標や目的を実現するためにグループ化された Azure
Policy の定義またはルールのコレクション
セキュリティ
イニシアチブは、一連のポリシーを論理的にグループ化して単一の項目として扱うことで、ポリシーの管理を簡略化
カスタム Azure セキュリティ イニシアチブとポリシーを作成する
カスタム
イニシアチブは、セキュリティで保護されたスコアには含まれていませんが、作成したポリシーに環境が従っていない場合は、レコメンデーションを受け取ります。
作成したカスタム
イニシアチブはすべてのレコメンデーションの一覧に表示されます。イニシアチブごとにフィルター処理して、イニシアチブに関する推奨事項を確認することができます。
目指せ!トップガン - クラウドセキュリティ 3回目:CISOの質問にタイムリーに応えるための10の方法(前編)
どのアプリケーションを仮想マシン上で実行できるようにするかを制御することができるインテリジェントで自動化されたソリューション
適応型アプリケーション制御は、既知の安全なアプリケーションの許可リストを定義し、不正なアプリケーションの実行を防止する
適応型アプリケーション制御を有効にして構成した場合、安全なものとして定義したもの以外のアプリケーションが実行されると、セキュリティ
アラートが表示される
適応型アプリケーション制御を使用して、マシンの攻撃対象領域を減らす
適応型アプリケーション制御とは、マシンに対して既知の安全なアプリケーションの許可リストを定義するためのインテリジェントで自動化されたソリューションです。
サポートされているマシン:
Windows および Linux が実行されている
Azure および Azure 以外のマシン
Azure Arc マシン
Defender for Cloud
は、セキュリティの脆弱性と脅威を監視するために、
Azure 仮想マシン
(VM)、仮想マシンスケールセット、IaaS コンテナー、非 Azure
(オンプレミスを含む) マシンからデータを収集します。
一部の Defender
プランでは、ワークロードからデータを収集するために監視コンポーネントが必要になります。
不足している更新プログラム、OS
のセキュリティ設定ミス、エンドポイント保護のステータス、正常性と脅威の防止を可視化するためには、データ収集が欠かせません。
データ収集を必要とするのは、コンピューティング リソース
(VM、仮想マシン スケール セット、IaaS コンテナー、非 Azure
コンピューターなど) だけです。
Defender for Cloud によるデータの収集方法
データは以下を使用して収集されます。
- Azure Monitor エージェント
(AMA)
- Microsoft Defender for Endpoint (MDE)
- Log Analytics
エージェント
- Kubernetes 用の Azure Policy
アドオンなどのセキュリティ コンポーネント
Microsoft Defender for Cloud を使用してサーバーを保護するために Azure Monitor エージェントをデプロイする
自動的に Azure Monitor エージェントをサーバーにデプロイできます。
ラボ 14: Microsoft Defender for Cloud
Microsoft Defender for Cloud によって監視される Azure リソースは何ですか?
仮想マシン (VM) ( Cloud Servicesを含む)
Virtual Machine Scale
Sets
製品概要に記載されているさまざまな Azure PaaS サービス
Log Analytics エージェント インストールの自動プロビジョニングでは、何をもって VM を適格と見なしますか?
Windows または Linux IaaS VM は、次の条件で適格とします。
-
現在、Log Analytics エージェント拡張機能が VM
にインストールされていない。
- VM が実行状態である。
- Windows
または Linux Azure 仮想マシン
エージェントがインストールされている。
- VM は、Web アプリケーション
ファイアウォールや次世代ファイアウォールなどのアプライアンスとしては使用されません。
Microsoft Defender for Cloud データを継続的にエクスポートする
Microsoft Defender for Cloud では、詳細なセキュリティ
アラートと推奨事項が生成されます。
これらのアラートと推奨事項の情報を分析するために、
それらを
Azure Log Analytics、Event
Hubs、または別の SIEM、SOAR、または IT
サービス管理ソリューションにエクスポートできます。
SQL Database と Azure Synapse Analytics のアラート
A possible vulnerability to SQL Injection (SQL
インジェクションにつながる可能性のある脆弱性)
アプリケーションにより、データベースでエラーのある
SQL ステートメントが生成されました。 これは、SQL
インジェクション攻撃に対する脆弱性があることを示している可能性があります。
エラーのあるステートメントの理由としては、次の 2 つが考えられます。
アプリケーション コードの欠陥により、エラーのある SQL
ステートメントが作成された可能性がある。 または、アプリケーション
コードまたはストアド
プロシージャでユーザー入力がサニタイズされず、エラーのある SQL
ステートメントが作成され、SQL
インジェクションに悪用される可能性がある。
Potential SQL injection(SQL インジェクションの可能性)
SQL
インジェクションに脆弱な特定されたアプリケーションに対してアクティブな悪用が発生しました。
これは、攻撃者が脆弱なアプリケーション コードまたはストアド
プロシージャを使用して、悪意のある SQL
ステートメントを挿入しようとしていることを意味します。
クイックスタート: セキュリティ アラートの電子メール通知を構成する
アラート疲れを防ぐために、Defender for Cloud
は送信メールの量を制限します。 各サブスクリプションについて、Defender
から次のようにメールが送信されます。
-
重要度が高いアラートに関しては、1 日あたり約 4 通のメール
-
重要度が中程度のアラートに関しては、1 日あたり約 2 通のメール
-
重要度が低いアラートに関しては、1 日あたり約 1 通のメール
Microsoft Defender for Cloud から外部へのアラート通知方法について
デメリット
通知が抑制されており、通知間隔やメール通知量が制限されています。
重要度が高いアラートでも、6時間間隔、1通のみです。
ワークフローの自動化とは、グループ化された手順の集合であり、セキュリティ対応チームは、1
回のクリックで実行できます。
これらの手順は、特定のアラートが検出された場合に、Defender for Cloud
で実行されます。 これらのアクションは、自動的にはトリガーされ
“ません”。ユーザーが操作して実行する必要があります。
ワークフローの自動化は、Azure
Logic Apps を基に構築されています。
クラウドトリガーに対する Microsoft Defender への応答を自動化する
Defender for Servers のデプロイを計画する
Just-In-Time (JIT) VM アクセスについて
JIT を構成して使用するために必要なアクセス許可は何ですか?
Just-In-Time アクセスを使用して管理ポートをセキュリティで保護する
サポート対象外 - 次の理由で JIT をサポートしていない VM。
-
ネットワーク セキュリティ グループ (NSG) または Azure
ファイアウォールが見つからない - JIT では、NSG
が構成されていることか、ファイアウォール構成 (またはその両方)
が必要です
- クラシック VM - Azure Resource Manager
を使用してデプロイされた VM は JIT でサポートされます。
- その他 -
サブスクリプションまたはリソース グループのセキュリティ ポリシーで JIT
ソリューションが無効になっている場合です。
Microsoft Defender for Cloud から VM で JIT を有効にする
Azure 仮想マシンの接続ページから JIT が有効な VM へのアクセス権を要求する
[接続] ページを開き、[アクセス権の要求] を選択
Azure およびハイブリッド マシンに対する Defender for Cloudの統合された Qualys 脆弱性評価スキャナー
Microsoft Defender for Storage の概要
Microsoft Defender for Storage を有効にする
保護されるストレージの種類:
Blob Storage (Standard/Premium
StorageV2、ブロック BLOB アカウント)
Azure Files (REST API および SMB
経由)
Azure Data Lake Storage Gen2 (階層型名前空間 (HNS)
が有効になっている Standard/Premium アカウント)
Microsoft Defender for Containers の概要
Microsoft Defender for Azure SQL の概要
データベースの潜在的な脆弱性を検出して軽減するのに役立ち、データベースに対する脅威を示す可能性のある異常なアクティビティに対するアラートを提供します。
-
脆弱性評価: データベースをスキャンして、脆弱性を検出、追跡、修復します。
脆弱性評価の詳細を確認してください。
- 脅威に対する保護: SQL Advanced
Threat Protection に基づいて、詳細なセキュリティ
アラートと推奨されるアクションを受け取り、脅威を軽減します。
SQL 脆弱性評価は、データベースの脆弱性を特定するのに役立ちます
クイックスタート: Azure 以外のマシンを Microsoft Defender for Cloud に接続する
Azure Connected Machine エージェントの概要
Azure Connected Machine エージェントは、Azure Arc
によってサポートされるサーバーにインストールするパッケージです。
このエージェントは、Azure
への接続と接続されたマシンの Azure ID を管理します。
TCP ポート 443
を介して Azure Arc へのアウトバウンド通信を安全に行います。
クイックスタート: Azure Arc 対応サーバーにハイブリッド マシンを接続する
Microsoft Defender for Cloud での Endpoint Protection に関する評価と推奨事項
オンプレからクラウドまで幅広く監視を行うことができるオールインワンな監視サービス
Microsoft
Sentinel
は、クラウドネイティブ型のスケーラブルなセキュリティ情報イベント管理(SIEM)および
セキュリティ オーケストレーション(SOAR)ソリューション
Microsoft Sentinel
は、インテリジェントなセキュリティ分析と脅威インテリジェンスを企業全体に提供します。
Microsoft Sentinel
を使用すると、攻撃の検出、脅威の可視化、予防的ハンティング、脅威への対応のための単一ソリューションが得られます。
Azure Sentinel でログ収集・分析基盤を構築してみた① ~Windows セキュリティイベントの収集~
Microsoft Sentinel とは?導入でできる4つの機能や導入メリットを解説
ワークスペースに Microsoft Azure Sentinel をオンボードしたら、データ コネクタを使用して Microsoft Sentinel へのデータの取り込みを開始できます。
Microsoft Azure Sentinel データ コネクタを見つける
Azure Active Directory Identity Protection
Log Analytics テーブル SecurityAlert
データ インジェスト方法 Azure
サービス間の統合:診断設定ベースの接続
Log Analytics テーブル
AzureDiagnostics
Azure サービス間の統合:
Log Analytics エージェントベースの接続
(レガシ)
ログ フォワーダーをデプロイして Syslog および CEF ログを Microsoft Sentinel に取り込む
Syslog と CEF ログを Microsoft Sentinel に取り込むには (特に Log
Analytics
エージェントを直接インストールできないデバイスとアプライアンスから)、
デバイスからログを収集して
Microsoft Sentinel ワークスペースに転送する Linux
マシンを指定して構成する必要があります
デバイスまたはアプライアンスの CEF 形式のログを Microsoft Sentinel に取得する
Azure Sentinel の分析ルールを使った脅威の検出
分析ルールとは、
集められたログの中から不審なものはどれかという定義を行い、脅威の検出を行うものです。
Azure
Sentinel
には多数の分析ルールのテンプレートが用意されており、それらによって脅威を検出し、攻撃から守ることができます。
分析ルールを見るには、Azure
Sentinel の分析ブレードを開きます。
Azure Sentinel でログ収集・分析基盤を構築してみた② クエリによる脅威検知
[規則のテンプレート]
をクリックし、[ルールの種類]から「Scheduled」を選択します。
[データソース]をクリックし、
「セキュリティイベント」を選択します。
Microsoft Sentinel でアラートに含まれるカスタム イベントの詳細を表示する
スケジュールされたクエリ分析ルールを使用すると、Microsoft Sentinel
に接続されたデータ
ソースのイベントを分析し、それらのイベントの内容がセキュリティの観点から重要な場合にアラートを生成できます。
これらのアラートは、Microsoft Sentinel
のさまざまなエンジンを使用してさらに分析、グループ化、フィルター処理が行われ、SOC
アナリストにとって注意が必要なインシデントへと抽出されます。
Sentinel におけるインシデントとは「関連するアラートをまとめたグループ」
Microsoft セキュリティ アラートからインシデントを自動的に作成する
セキュリティツールなどを活用し、組織のシステムやネットワークなどを探索し、悪意のある活動や脅威の兆候を発見し対処するプロセス
アラートなどを通じて受動的に脅威を検知する「脅威検知」に対して、脅威インテリジェンスやアノマリ、IoCを元に隠れた兆候を見つけ出す点が強調されています。
Microsoft Sentinel によるハンティング中にデータを追跡する
Microsoft Sentinel - Logs で実行したクエリが、関連すると思われるクエリ結果と共に保持される
Microsoft Sentinel でのセキュリティ オーケストレーション、オートメーション、応答 (SOAR)
自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する
Microsoft Sentinel のプレイブックを使用して脅威への対応を自動化する
プレイブックは、脅威への対応を自動化および調整する
チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する
Microsoft Sentinel のプレイブックは、エンタープライズ全体のシステムでタスクとワークフローをスケジュール、自動化、調整するのに役立つクラウド サービスである Azure Logic Apps で作成されたワークフローに基づいています
Microsoft Sentinel インシデント (プレビュー)
ほとんどのインシデント自動化シナリオに推奨されます。
プレイブックは、エンティティやアラートを含むインシデント
オブジェクトを受け取ります。
このトリガーを使用すると、プレイブックをオートメーション
ルールにアタッチできるため、Microsoft Sentinel
でインシデントが作成されたときにそれをトリガーでき、そのインシデントにオートメーション
ルールのベネフィットのすべてを適用できます。
Microsoft Sentinel アラート (プレビュー)
アラートに対して Microsoft Sentinel
ポータルから手動で実行する必要のあるプレイブック、またはアラートに対してインシデントを生成しないスケジュールされた分析ルールに推奨されます。
Microsoft Sentinel エンティティ (プレビュー)
調査または脅威ハンティングのコンテキストで、特定のエンティティに対して手動で実行する必要があるプレイブックに使用します。
Microsoft Sentinel の Kusto 照会言語
SC-200: Kusto クエリ言語 (KQL) を使用して Microsoft Sentinel のクエリを作成する
Key
Vaultは、Azureの主要な管理ソリューションの一つで、シークレットやキーなどの機密情報を安全に格納し、アクセスを制御できます。
シークレットとキーの違いは、シークレットは文字列として扱われる汎用的なデータ(例えばパスワードや接続文字列)であり、
キーは暗号化や署名などの暗号操作に使用される非対称鍵ペアです。
証明書もKey
Vaultに格納できますが、証明書が作成されると同じ名前でキーとシークレットも作成されます。
「Azure Key Vault」を使ってセキュアなアプリを作ろう
Azure Key Vaultとは?クラウドへの安全なアクセスを実現するセキュリティサービス
Azure Key Vault により、データの暗号化に使用される暗号化キーの作成と制御が簡単になります。
パスワードやデータベース接続文字列などの汎用シークレットのセキュリティで保護されたストレージ
開発者から見ると、Key
Vault API はシークレット値を文字列として受け取って返される
Key Vault
内のシークレットはすべて、暗号化した状態で格納される
Key Vault と Azure PowerShell を使用したストレージ アカウント キーの管理 (レガシ)
Key Vault でストレージ アカウント
キーを定期的に再生成する場合は、
Azure PowerShell の
Add-AzKeyVaultManagedStorageAccount
コマンドレットを使用して、
再生成期間を設定できます。
アクセスモデルとして重要なのは下記の2点です。
・
管理プレーンとデータプレーンの2層に分かれている
・
アクセスマネージメントは、Azure AD の Security Principal
をベースに行われる
どちらのプレーンでも、認証にはAzure
ADが使われます。
管理プレーン:
コンテナーの作成と削除、アクセス ポリシーなど、Key Vault
そのものを管理
データ プレーン :アクセス
ポリシーに基づいて、どのプリンシパルが、キー
コンテナーに格納されているデータを操作できるかを管理
管理プレーンにアクセス権がないと、コンテナの操作はできない
データプレーンにアクセス権がないと(アクセス
ポリシーで許可されていないと)データにはアクセスできない
データプレーンのアクセスポリシーの変更は、管理プレーンの権限で、
アクセスポリシーの変更権とデータへのアクセス権とが別れているところが味噌になっています。
Azure のロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する
Key Vault データ プレーン操作のための Azure の組み込みロール
Azure portal にサインインします。
[リソース グループ]
を選択し、キー コンテナーが含まれるリソース
グループを選択します。
[アクセス制御 (IAM)]
を選択します。
[ロールの割り当ての追加] を選択します。
[ロール]
で、キー コンテナーに関連するロールを選択します。例えば、Key Vault Secrets Officer や [Key
Vault Keys Operator] などです。
[割り当て先] で、キー
コンテナーを選択します。
[メンバーの選択]
で、アクセス許可を付与するユーザーやグループを検索して選択します。
[保存]
を選択して、ロールの割り当てを完了します。
キー コンテナーとその内部にあるすべてのオブジェクト
(証明書、キー、シークレットを含む) に対して、すべてのデータ
プレーン操作を実行
キー コンテナー
リソースの管理やロール割り当ての管理はできない
キー コンテナーを管理キー コンテナーを管理できる
Azure RBAC
でのロール割り当ては許可されない
シークレット、キー、証明書へのアクセスも許可されない
キーコンテナーのキーに対して、アクセス許可の管理を除く任意の操作を実行
キーを使用した暗号化操作を実行
Key Vault Crypto Service Encryption User
キーのメタデータを読み取り、wrap および unwrap 操作を実行
キー コンテナーとその証明書、キー、シークレットのメタデータを読み取ります。 シークレット コンテンツやキー マテリアルなどの機密値を読み取ることはできません。
キーコンテナーのシークレットに対して、アクセス許可の管理を除く任意の操作を実行
Key Vault アクセス ポリシーは、
特定のセキュリティ プリンシパル
(ユーザー、アプリケーション、またはユーザー グループ) が、
Key Vault
の
シークレット、キー、証明書に対して、
さまざまな操作を実行できるかどうかを決定します
Key Vault による認証は、特定のセキュリティ プリンシパルの ID
を認証する役割を担当する Azure Active Directory
と連携して機能します。
アプリケーションの場合、サービス
プリンシパルを取得するには次の 2 つの方法があります。
-
アプリケーションに対して、システムに割り当てられたマネージド ID
を有効にする。
- マネージド ID を使用できない場合は、代わりに Azure
AD テナントにアプリケーションを登録します。
また、登録によって、すべてのテナントでそのアプリを示す 2
つ目のアプリケーション オブジェクトも作成されます。
Key Vault の認証オプションは、Azure Active Directory (Azure AD)
と連携して、セキュリティ プリンシパルの ID
を認証します。
セキュリティ
プリンシパルは、ユーザー、グループ、サービス、またはアプリケーションを表します。
Key
Vault の認証オプションには以下のようなものがあります3:
-
アプリケーションのみ: サービス プリンシパルまたはマネージド ID
を使用します。
- ユーザーのみ:
テナントに登録されている任意のアプリケーションからアクセスします。
-
アプリケーションとユーザー (複合 ID):
アプリケーションとユーザーの両方が必要です。
このオプションを使用するには、Azure
AD
でアプリケーションを登録し、ユーザーの委任された権限を付与する必要があります。また、Key
Vault でアクセス
ポリシーを設定し、アプリケーションとユーザーの両方に対して適切な権限を割り当てる必要があります
–enable-purge-protection 引数がコンテナー自体で有効になっている場合。 この場合、Key Vault では、元のシークレット オブジェクトは、オブジェクトを完全に削除する削除対象としてマークされたときから 90 日間待機します。
論理的な削除と消去保護を使用した Azure Key Vault の回復の管理
シークレットを完全に削除するには、2 つの操作を行う必要があります。
まず、ユーザーはオブジェクトを削除する必要があり、これによって論理的に削除された状態になります。
次に、ユーザーは論理的に削除された状態のオブジェクトを消去する必要があります。
消去操作には、追加のアクセス ポリシーのアクセス許可が必要です。
論理的に削除された状態のシークレットを消去するには、サービス
プリンシパルに追加の “消去” アクセス
ポリシーのアクセス許可が付与されている必要があります。
消去アクセス
ポリシーのアクセス許可は、既定では、キー
コンテナーとサブスクリプションの所有者を含むサービス
プリンシパルには付与されないため、意図的に設定する必要があります。
論理的に削除されたシークレットを削除する際に昇格されたアクセス
ポリシーのアクセス許可を要求することで、シークレットを誤って削除する可能性が減少します。
消去保護は Key Vault のオプションの動作であり、既定で有効になっていません。 消去保護は、論理的な削除が有効な場合にのみ有効にすることができます。
論理的な削除と消去保護を使用した Azure Key Vault の回復の管理
消去保護は、悪意のある内部関係者によってキー
コンテナー、キー、シークレット、証明書が削除されるのを防ぐように設計されています。
構成可能な保持期間中であればいつでも、項目を回復できます。
キー
コンテナーは、保持期間が経過するまでは、完全に削除したり消去したりできません。
保持期間が経過すると、キー コンテナーまたはキー コンテナー
オブジェクトは自動的に消去されます。
消去保護は、管理者のロールまたはアクセス許可によって消去保護を上書き、無効化、または回避することができないように設計されています。
Microsoft
を含むすべてのユーザーは、いったん有効にされた消去保護は、無効にしたり上書きしたりできません。
つまり、キー コンテナー名を再利用するには、最初に削除されたキー
コンテナーを回復するか、保持期間が経過するまで待つ必要があります。
Azure Key Vault のキー コンテナーを完全に削除する
PowerShell を使用して Azure の Key Vault を完全に削除する
キー コンテナー オブジェクト (シークレット、キー、証明書など)
をバックアップすると、そのオブジェクトは、バックアップ操作によって、暗号化された
BLOB としてダウンロードされます。
Azure の外部でこの BLOB
の暗号化を解除することはできません。
この BLOB
から有効なデータを取得するには、同じ Azure サブスクリプションと Azure
地域内のキー コンテナーに BLOB を復元する必要があります。
Key Vault ファイアウォールを有効にする (仮想ネットワーク - 動的 IP)
仮想ネットワーク内にリソースを作成し、特定の仮想ネットワークおよびサブネットからのトラフィックがご利用のキー コンテナーにアクセスするのを許可する必要があります
Azure Key Vault のネットワーク設定を構成する
Azure Key Vault と Azure Policy を統合する
Azure Storage 内のデータへのアクセスを承認する
※表参照
データプレーンの操作に対しては AAD 認証に加えて共有キーや SAS を利用した認証とアクセス制御が可能
ストレージ アカウント アクセス キーとは、Azure Storage
に格納されたデータへのアクセスを認証するために使用される 512
ビットのキーのこと。
ストレージ アカウントごとに 2
つのキーが生成され、どちらか一方を使用してアクセスできます。
アクセスキーの管理には Azure Key Vault
を使用し、キーのローテーションと再生成は定期的に行うことを推奨
Azure
Key Vault
を使用すると、アプリケーションを中断することなく簡単にキーをローテーションできます。
また、キーを手動でローテーションすることもできます
ストレージアカウントのキーはストレージアカウントが作成されて初めて払い出されます。
つまり少なくともストレージアカウントを作成し、共有キーを払い出す操作に関しては
Azure AD 認証を使用する必要があります。
このことからも「データプレーンの操作しか出来なさそうだな」ということが分かるかと思います。
なおストレージアカウントキー方式は最も古くから提供されている認証方式なのですが、現在では積極的な利用をあまりおススメしていません。 このキーを知っていればストレージアカウントのデータプレーンに対する任意の操作が可能ですので、権限が強すぎるというのが問題です。 アプリケーション設計時に認証方式に迷った場合は、原則として前述の AAD 認証か後述の SAS をご検討ください。
BLOB データへのアクセスを認可するには、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、サービス プリンシパル (ユーザー、グループ、またはアプリケーション) にアクセス許可を割り当てる必要があります。
Azure Active Directory を使用して BLOB へのアクセスを認可する
Azure Storage では、Azure AD を使用して BLOB
データへの要求を認可することがサポートされています。
Azure AD
では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、サービス
プリンシパル (ユーザー、グループ、またはアプリケーションのサービス
プリンシパルである可能性があります) にアクセス許可を付与します。
セキュリティ プリンシパルは、Azure AD によって認証されて、OAuth 2.0
トークンを返します。 その後、そのトークンを、Blob service
に対する要求を認可するために使用できます。
Azure AD を使用して認可すると、共有キーによる認可よりも優れたセキュリティと使いやすさが実現されます。 Microsoft では、必要最小限の特権でアクセスできるようにするために、可能な場合は BLOB アプリケーションで Azure AD の認可を使用することをお勧めします。
AAD
でユーザーないしはアプリケーションを認証し、
そこで得られたアクセストークンを
REST API に提示、
操作可否を RBAC で制御する方式
AAD
認証でデータプレーンにアクセスする
データプレーン用の操作なので、先ほどとは別の
RBAC ロール割り当てが必要になります。
例えば下記では仮想マシンの
Managed ID に対して、とあるリソースグループに対する ストレージ Blob
データ共同作成者 ロールを割り当てています。
この Managed ID
を使用するアプリケーションが、データプレーンの API を操作して Blob
の書き込みや読み取りをする
共有アクセス署名 (SAS) とは、Azure Storage
リソースへの制限付きアクセス権を付与する URI
SAS
を使用すると、ストレージ
アカウント内のリソースへのセキュリティで保護された委任アクセスが可能になる
SAS
には、アカウント SAS とサービス SAS の2種類がある
共有アクセス署名 (SAS) は、Azure Storage
リソースへの制限付きアクセス権を付与する URI です。
ストレージ
アカウント キーで信頼する必要はありませんが、
特定のストレージ
アカウント
リソースへのアクセスが必要なクライアントには、共有アクセス署名を提供できます。
これらのクライアントに SAS URI
を配布して、指定したアクセス許可セットで、指定した期間、リソースへのアクセスを許可できます。
Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する
SAS
を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。
次に例を示します。
・ クライアントがアクセスできるリソース。
・
それらのリソースに対するアクセス許可。
・ SAS が有効である期間。
サービス SAS とアカウント SAS は、どちらもストレージ アカウント キーを使用して署名されます。
AzureのSAS(共有アクセス署名)を分かりやすく解説する
SAS : Shared Access Signature
方式も事前にクライアントにキー(のようなもの)を共有する方式なのですが、
Blob やコンテナといった限定的なスコープに対して、Read のみとか、IP
アドレス制限、時間制限 といったきめ細かなアクセス制御が可能です。
AAD
認証を使ったデータアクセスが難しいなどの制約がある場合は、ストレージアカウントキーではなくこちらの
SAS キーを使用すると良いでしょう。
ストレージ
アカウント内の複数のサービスへのアクセスを一度に委任する。
サービス
SAS を使用して実行できるすべての操作は、アカウント SAS
でも実行できる
サービス SAS で許可されていない BLOB
コンテナー、テーブル、キューおよびファイル共有の読み取り、書き込みおよび削除操作へのアクセスも委任できる
※保存されているアクセス
ポリシーは、現在、アカウント SAS ではサポートされていません。
Azure Blob Storage、Azure Queue Storage、Azure Table Storage、Azure Filesのいずれかのストレージ サービス内のリソースへのアクセスを委任する
格納されたアクセス ポリシーは、サーバー側のサービス SAS
に対する追加のレベルの制御を提供
格納されたアクセス
ポリシーを設定することで、SAS
をグループ化し、ポリシーによって規定されたパラメーターで SAS
を管理できる
注意
コンテナーに格納されているアクセス
ポリシーは、コンテナー自体またはコンテナーに含まれる BLOB
にアクセス許可を付与する共有アクセス署名に関連付けることができます。
同様に、ファイル共有に格納されているアクセス
ポリシーは、共有自体またはファイルに対するアクセス許可を付与する共有アクセス署名に関連付けることができます。
保存されているアクセス
ポリシーは、ユーザー委任 SAS またはアカウント SAS
ではサポートされていません。
格納されているアクセス ポリシーを取り消すには、そのポリシーを削除するか、署名付き識別子を変更して名前を変更するか、有効期限を過去の値に変更します。
BLOB コンテナーごとの保存されるアクセス ポリシーの最大数 5
Microsoft Azure Storage Explorer は、Windows、macOS、Linux での Azure Storage データの操作を容易にするスタンドアロン アプリ
Azure Storage では、Microsoft のマネージド キー を利用してストレージ アカウント内のデータを暗号化することも、カスタマー マネージド キー で暗号化を管理することもできます
既定では、新しいストレージ アカウント内のデータは Microsoft マネージド キーで暗号化されます
Blob Storage と Azure Files でデータの暗号化と復号に使用する目的で “カスタマー マネージド キー” を指定できます
Azure Key Vault に既存のストレージ アカウントのカスタマー マネージド キーを構成する
新規または既存のキー コンテナーを使用して、カスタマー マネージド
キーを格納することができます。
ストレージ
アカウントとキーコンテナーは、同じテナント内の異なるリージョンまたはサブスクリプションに存在する場合があります。
Blob Storage でデータの暗号化と復号に使用する目的で “カスタマー指定のキー” を指定できます
Azure Storage Analytics ログを有効にして管理する (クラシック)
診断ログは、ストレージ アカウントの $logs という名前の BLOB
コンテナーに保存されます。
ログ データを表示するには、Microsoft
Azure Storage Explorer などのストレージ
エクスプローラーを使用するか、プログラムによってストレージ クライアント
ライブラリまたは PowerShell を使用します。
不変ストレージを使用してビジネスに不可欠な BLOB データを保存する
Azure Blob Storage
の不変ストレージを使用すると、ユーザーはビジネスに不可欠なデータを WORM
(Write Once, Read Many) 状態で保存できます。
WORM
の状態では、ユーザーが指定した期間、データを変更および削除できません。
BLOB データに 不変ポリシー
を構成することにより、上書きや削除からデータを保護することができます。
BLOB
データに不変ポリシーを構成することにより、上書きや削除からデータを保護することができます。
不変性ポリシーには、時間ベースの保持ポリシー
と 訴訟ホールド が含まれています。
Azure Storage のプライベート エンドポイントを使用する
Azure Storage ファイアウォールおよび仮想ネットワークを構成する
暗号化スコープを使用すると、異なる顧客が所有する、同じストレージ アカウントに存在するデータの間にセキュリティで保護された境界を作成できます。
Azure Firewallを作成しただけでは、仮想マシンの送信/受信の通信はファイアウォールを経由してくれないため、独自のルーティング規則を定義するための「ルートテーブル」のリソースを作成していきます。
DNAT ルールは、ファイアウォールのパブリック IP
アドレスを介した受信トラフィックを許可または拒否します。
パブリック
IP アドレスをプライベート IP アドレスに変換する場合は、DNAT
規則を使用できます。
Azure Firewall のパブリック IP
アドレスを使用して、インターネットからの受信トラフィックをリッスンし、トラフィックをフィルター処理して、このトラフィックを
Azure の内部リソースに変換できます。
Azure Storage BLOB、ファイル、キュー、テーブルに加えて、Azure Data
Lake Storage エンティティと Azure マネージド
ディスクのアップロード、ダウンロード、管理を行うことができます。
ストレージのアクセス許可とアクセス制御、階層、規則を構成できます。
Microsoft Azure Storage Explorer は、Windows、macOS、Linux での Azure Storage データの操作を容易にするスタンドアロン アプリ
Azure Instance Metadata Service
Azure PowerShell を使用して Azure Marketplace VM イメージを検索して使用する
特定のパブリッシャーID(パブリッシャー)、オファーID(製品)、およびプランID(名前)の条件に同意または拒否します。Get-AzMarketplaceTermsを使用して、契約条件を取得してください。
Azure Disk Encryption では、Azure Key Vault を使用して、ディスク暗号化キーとシークレットを制御および管理
Windows VM 用の Azure Disk Encryption
Linux VM に対する Azure Disk Encryption
Azure Disk Encryption は、Basic、A シリーズ VM または次の最小メモリ要件を満たしていない仮想マシンでは利用できません。
Windows VM で Azure Disk Encryption のキー コンテナーを作成して構成する
警告
暗号化シークレットがリージョンの境界を越えないようにするには、暗号化する
VM と同じリージョンとテナントにキー
コンテナーを作成して使用する必要があります。
Azure プラットフォームには、Key Vault
内の暗号化キーまたはシークレットへのアクセス権を付与する必要があります。
これにより、ボリュームをブートして暗号化する際に、それらの情報を
VM に提供できるようになります。
Key Vault
内の暗号化キーまたはシークレットへのアクセス権を付与する必要があります。
これにより、ボリュームをブートして暗号化する際に、それらの情報を
VM に提供できるようになります。
作成時に
ディスクの暗号化、デプロイ、またはテンプレートのデプロイに対してキーコンテナーを有効にしなかった場合は、その高度なアクセスポリシーを更新する必要があります。
Key Vault VM 拡張機能では、Azure キー コンテナーに保存されている 証明書 の自動更新が行われる
Windows 用の Microsoft マルウェア対策拡張機能
Azure Desired State Configuration 拡張機能ハンドラーの概要
Azure の望ましい状態の構成 (DSC) 拡張機能の主なユース ケースは、VM を
Azure オートメーション状態構成 (DSC)
サービスにブートストラップすることです。
このサービスには、VM
構成の継続的な管理や、Azure
監視などの他の運用ツールとの統合などの利点があります。
拡張機能を使用して
VM をサービスに登録すると、Azure
サブスクリプション間でも機能する柔軟なソリューションが提供されます。
Azure Diagnostics 拡張機能は、仮想マシンを含む Azure コンピューティング リソースのゲスト オペレーティング システムから監視データを収集する、Azure Monitor のエージェントです。
Linux Diagnostic Extension 4.0 を使用して、メトリックとログを監視する
Windows 用の Log Analytics 仮想マシン拡張機能
Azure 仮想マシンに Log Analytics エージェントがインストールされ、仮想マシンが既存の Log Analytics ワークスペースに登録されます。
新しい Azure ノードへの Windows 仮想マシンの再デプロイ
VM を再デプロイすると、Azure では VM がシャットダウンされ、Azure インフラストラクチャ内の新しいノードに VM が移動されてから、電源が再びオンにされて、すべての構成オプションと関連するリソースが保持されます